home *** CD-ROM | disk | FTP | other *** search
- Path: mail2news.demon.co.uk!hpl3sn03.cern.ch
- From: Dan Pop <danpop@mail.cern.ch>
- Newsgroups: comp.lang.c++,comp.lang.c
- Subject: Re: Hungarian notation
- Date: Thu, 18 Jan 1996 13:11:37 +0100
- Organization: CERN European Lab for Particle Physics
- Message-ID: <9601181211.AA03705@dxmint.cern.ch>
- References: <4dhkae$an9@blackice.winternet.com> <821890870snz@genesis.demon.co.uk> <30fd5306.3171520@nntp.ix.netcom.com>
- X-NNTP-Posting-Host: hpl3sn03.cern.ch
- X-Newsreader: NN version 6.5.0 #7 (NOV)
- X-Mail2News-Path: dxmint.cern.ch!hpl3sn03.cern.ch
-
- miker3@ix.netcom.com (Mike Rubenstein) writes:
-
- >There is one possibility that makes the cast to long double
- >potentially dangerous according to the standard. There is no
- >guarantee in the standard that all possible values of an integral type
- >can be converted to long double.
-
- Such a guarantee actually exists.
-
- (ANSI classic) 3.2.1.5 Usual arithmetic conversions
-
- Many binary operators that expect operands of arithmetic type cause
- conversions and yield result types in a similar way. The purpose is
- to yield a common type, which is also the type of the result. This
- pattern is called the usual arithmetic conversions: First, if either
- operand has type long double, the other operand is converted to long
- double.
-
- The last statement (sort of) guarantees that any arithmetic type can be
- safely converted to long double, even if some information is lost in the
- conversion (I'm typing this text on a machine where both long and long
- double have the same size, hence some long values cannot be converted to
- long double without loss of precision).
-
- Dan
- --
- Dan Pop
- CERN, CN Division
- Email: danpop@mail.cern.ch
- Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland
-